Sams Teach Yourself MCSE Windows NT Server 4 in 14 Days
(Publisher: Macmillan Computer Publishing)
Author(s): David Schaer, et al
ISBN: 0672311283
Publication Date: 12/15/97

Chapter 14
NT Server Troubleshooting Guidelines

by Marcus Barton

14.1. Overview

Troubleshooting is an art. For the most part, troubleshooting is something that you learn with experience. Humans are creatures of habit. Knowing this, you can surmise that humans learn things best through repetition and experience. You learn troubleshooting best by using a product and then seeing first hand what things might go wrong with it. You should spend some time in a chair sitting in front of a monitor and using Windows NT Server. Take what you learn in this chapter and apply it. It will prove invaluable at test time.

In this chapter, you learn some tools and techniques for troubleshooting Windows NT problems about which you might not have read in other chapters.

14.1.1. Objectives

The following list shows the Microsoft exam objectives for the topic of troubleshooting. Although other chapters covered many of these objectives, it is important that you know how to appropriately fix the troubleshooting problems you are required to understand for the exam.

•  Resolve installation failures.

•  Resolve boot failures.

•  Resolve configuration errors.

•  Resolve printer problems.

•  Resolve RAS problems.

•  Resolve connectivity problems.

•  Resolve resource access problems and permission problems.

•  Resolve fault-tolerance failures. Fault-tolerance methods include

•  Tape backup

•  Mirroring

•  Stripe set with parity

•  Disk duplexing

14.1.2. Fast Facts

The following list of facts is a concise picture of the information presented in this chapter. It acts both as an overview for the chapter and as a study aid to help you do any last-minute cramming.

•  The Emergency Repair Disk is computer-specific; the boot disk is not.

•  To create a boot disk, you must format the floppy in Windows NT.

•  The necessary files for a boot disk for an Intel-based computer are NTLDR, NTDETECT.COM, BOOT.INI, and NTBOOTDD.SYS (if the boot device is an SCSI).

•  If the BOOT.INI is not present at bootup, NTLDR attempts to load Windows NT from the WINNT directory on the first partition of the first disk on the first controller.

•  The default setting for a log file is a maximum size of 513KB with events that are older than seven days overwritten.

•  The Last Known Good configuration is saved when a user successfully logs on to a system after bootup. Also, the boot must have been accomplished without any critical errors.

•  Information dumped from the memory during an automatic recovery is saved as MEMORY.DMP by default.

14.2. Troubleshooting Methodology

You should develop a method for handling troubleshooting situations. After you find a method that works, stick to it. Creating a method is not easy, however, and so here are some guidelines to help you out. These guidelines are time-tested and work for most situations. Using these guidelines not only will help you determine your own method, but also will help you learn troubleshooting, should you not be experienced at it already.

14.2.1. Gathering the Facts

The first step in troubleshooting is gathering the facts. There is no way that you can troubleshoot a situation without having some facts. The more facts that you have, the more quickly and easily you can resolve the problem. Keep in mind that a fact only is something that you can verify as true. Often administrators let false guesses, which are nothing more than speculative fictions, lead them after much time-consuming effort to a dead end.

Symptoms, which are the end results of a problem, form part of these facts. By analyzing the symptoms, you can get closer to the problem that is causing them. After spending some time using a product, most administrators can resolve a problem by looking only at the symptoms. The infamous statement, “I’ve seen this before,” can be invaluable when you are troubleshooting.

What has changed since the last time something that isn’t working did work? Often you can resolve problems simply by asking that question. Quite possibly, whatever changed might be causing the problem. The fix usually is easy in this case: Change everything back to how it was before the problem.

Has what isn’t working ever worked? I know you think I’m joking, but numerous help desks spend countless hours on the phone trying to resolve a problem that they think (because the user hasn’t informed them otherwise) has worked at some time. If something has never worked, try starting it over (install a product a second time, begin a new process, and so on).

Was anything new installed or uninstalled? Installations sometimes can have detrimental effects on a server, especially if they replace that important DLL file with an older version. Equally as damaging is an uninstall that takes away files that other programs, especially the operating system, need.

Is all of the hardware working properly? No one likes a hardware failure; however, it does happen. Hardware doesn’t live forever, and so you should expect hardware failures. Having a few extras on hand doesn’t hurt anything, and if you think it hurts your wallet, think of how much it will cost you if the server is down until you can get a replacement part.